而這次的故事，也是發生在同一位設計身上(嘿！因為他很經典，有很多值得說的故事呀)
本次登場的是苦專2
苦專2這次的需求是一個從無到有的大型專案
在專案執行前有找設計、技術一起說明規格內容及相關規範
說明完成後，就放手讓設計去設計
設計完成時也有請苦專2看過一次
結果當專案開發的差不多時
技術將開發內容交接苦專2驗收
驗收過程發現有些地方的uxUX不是那麼的順暢
所以要求設計調整
設計回覆：你的規格又沒有這樣寫，我是照你的規格的做的(表不想調整)
苦專2：開始解釋為什麼要做這樣的調整請設計配合
設計：你當初規劃時為什麼不想清楚
苦專2：無語中(心表……)
後來，專案順利上線了
就在一次對客服說明的會議時被設計發現，介面有沒有照設計設計的樣式呈現
設計就和專案主管說這件事
專案主管就來怪罪苦主，你怎麼沒有檢查畫面？
苦專2：抱歉是我沒注意到
然後苦專2就愈想愈不對，因為專案主要的任務是讓功能可以如期如質的上線，而介面上的東西應該要由設計去檢查，所以事後向主管提出，希望在專案流程增加設計的介面確認流程，不過這個建議被駁回了，因為主管也覺得專案就是應該要負責整個專案，不該由設計檢查
如果你是苦主2，在遇到被設計噹你規格沒有這樣寫時，你會怎麼反應？
1.跟他說教，專案在上線前本來就是會因為驗收或是使用者需求而改變的，麻煩你調整
2.用官位壓他，我是專案你就是照我說的做
3.在事情結束時和他的主管反應請他改進
4.其他，請說明
如果是你是苦主2，在遇到介面和設計的設計有出入，但卻在事後才發現時你會怎麼辦？
1.先看落差的地方會不會影響使用者使用，如果不會，就找機會再來調整(通常是沒機會啦！XD)
2.要求技術趕快調整趕快上線
3.看主管指示再說
4.其他，請說明
你覺得介面確認的工作應該由誰負責才對？
1.設計：專案流程需要納入設計的檢核流程，因為很多設計的細節只有設計自己才會知道，而且東西是設計產出的他也需要負責任
2.專案：如文所述，他要負責全部
3.技術：技術在開發時，就應該認真的像大家來找碴那樣，和設計介面一一比對才對
4.其他，請說明
在你所任職的公司如果你也是專案成員的環節之一，對於此種情境，你會建議如何改善？
開放自由回應
※這是最近剛好看到的一篇文章，還蠻呼應這個主題的，也附上給大家參考
https://medium.com/as-a-product-designer/%E5%A6%82%E4%BD%95%E6%88%90%E7%82%BA%E4%B8%80%E5%80%8B%E7%88%9B-ux-%E8%A8%AD%E8%A8%88%E5%B8%AB-714797c8901b
如果你是苦主2，在遇到被設計噹你規格沒有這樣寫時，你會怎麼反應？
4.其他，請說明
如果是有規格需求書時，且需求書內真的沒有寫到，我也只能摸摸鼻子，請設計針對此需求進行修改。
如果是你是苦主2，在遇到介面和設計的設計有出入，但卻在事後才發現時你會怎麼辦？
3.看主管指示再說
你覺得介面確認的工作應該由誰負責才對？
4.其他，請說明
我的認知是：
專案：負責整體，包含
確認設計的內容、時程、預算、視覺化等等，是否符合預期。
確認技術的規格、時程、預算、功能性等等，是否符合預期。
確認上述兩項不符合預期的時候要如何調配、修改等等。
設計：負責所有視覺化相關作業。
技術：負責所有功能性相關作業。
設計依照需求書或規格書做出了「介面」、技術依照需求書或規格書賦予「功能」。
那誰要去確認「介面」跟「功能」能，當然就是Leader，也就是專案負責人。
「介面」不符合PM預期，那就請設計進行修改，然後PM再確認；
「功能」不符合PM預期，那就請技術進行修改，然後也是請PM再確認。
PM之所以不好當的原因就是，他要擔當「主導」「規劃」「溝通」「協調」「確認」的角色。
很不幸的，不論設計這個人是不是很難搞，以第三人的角度來看，「確認介面」的這件事情是要PM來負責的。
在你所任職的公司如果你也是專案成員的環節之一，對於此種情境，你會建議如何改善？
開放自由回應
我前公司也有類似的經驗。
某部門人員提出了IT系統需求，我們部門的同事依照「需求規格」進行程式設計。
程式設計前有和需求單位開會了解實際需求，並且得到最終結果後才進行開發。
開發過程中遇到問題時，我同事也有立即和需求單位進行確認，然後進行修改和調整。
開發過程到最終測試階段時，我同事也有請需求單位到測試機上去測試，問題在這裡產生了。
需求單位並沒有到測試機上進行任何測試。
需求單位並沒有到測試機上進行任何測試。
需求單位並沒有到測試機上進行任何測試。
然後需求單位就驗收完成了。
然後需求單位就驗收完成了。
然後需求單位就驗收完成了。
因為前公司存在一些改變不了的內部問題，所以這個程式開發完成後不到半個月，我同事也離職了。
這時候程式也正式上線了。
但，程式上線後，使用者卻反應有些功能違反人性操作。
這時，需求單位的那位需求者，卻反過來說「IT同仁沒有依照需求書進行開發」。
你不承認程式規劃是你沒有想好、卻不承認你是閉著眼睛驗收，卻把問題都都給開發人員。
WTF?
所以以上述我在前公司經歷過的，你，需求者，就等於該專案的PM了。
那你提出需求，你就應該掌或整個專案進度。
如果是開發人員不聽指揮，一意孤行，自顧自的把程式寫好就不管了，那開發人員的確有不可分割的責任。
但是PM在遇到這樣冥頑不靈的開發人員時，也要向上級主管報告，看是否能替換開發人員，或是讓上級主管去要求開發人員配合專案的需求去進行開發。
除非，這個開發人員是老闆兒子女兒，那這個專案就這樣了吧，沒救了。
回歸案例，專案的英文為：Projrect Manager，意即專案負責人或專案經理人。
那你就是這個專案最大的Leader，那不就應該是你要完全掌或專案的狀況嗎？
我認同專案管理人是需要掌控全局的，不過，在我過去的經驗裡，我會很希望技術在開發時可以主動反饋他遇到的問題或是難關，規格是我開的只要可以達成目的，用什麼方法都是有討論的空間在，而設計我是覺得那既然掛ui/ux那你就該做好把關的動作，就專案每個環節的成員都對這個專案有份責任在，而不是事情做完就不干自己的事了，所以相對的，當專案內容有所改變時，我也會習慣去修正我的規格並於相關人員同步，我白紙黑字有寫的就是我們有討論過的，我們一起扛（但我通常會保護技術和設計，讓火燒到我這裡就好，我在意我的團隊成員的安全感和向心力，所以飛到必要，是不太有可能從我的嘴裡說出，是你說要這樣做的話，因為我常常被這樣的話噹，不管話是主管說的還是我說的，我就是要扛，所以我知道這句話的殺傷力有多大）
而我過去的經驗中run專案最舒服的配置是，在需求萌芽時就會抓所有團隊成員一起了解和討論，讓他們可以站在自己的專業角度給出意見（有時這個討論會在我出第一版規格時）
接著技術開發有問題時，或是開發過程中客服有想到什麼對使用者有危害或是更好的建議，我都會先理解，再視調整的規模判斷能否併入或是一定非要改變不可
再來就是進設計階段時，設計會站在專案目的去檢視ux的動線做出比我規格更幫的視覺設計，pm不是全能如果全能了要其他團隊成員何用（團隊的意義絕對不是只有來減輕某人的工作量的，而是要發揮他的價值）
然後技術在套版完成時就要請pm確認，此時pm應該也要邀請設計做確認，畢竟行高、字的大小、顏色...是不是有套錯，說真的pm也沒有火眼金星，那些細節還是要設計本人才知，文中的案例有一個沒有提及的重點，這名設計告狀的內容是訊息視窗的按鈕不是他設計的圓角，以及行距跟他設計的不一樣，說真的，這種pm真心看不出來，如果pm並不知道設計有動過按鈕設計，又怎知產出成品與設計有落差
最後，當程式開發完成交附測試前，技術必須確保功能們的動線是可以正常執行的，不然自己沒測過就交付出去，說實在有點不負責任，自己做的東西必須要確認過才能釋出（我過去曾經很悲慘的在驗收時走一步卡一步，這樣反而會讓時間消耗在沒有效率的事情上
接著pm初步驗收完，確認大方向都完成了，就會請行銷客服一起測試，過去的經驗我不會寫測試計畫給他們，因為我認為他們就是最好取得的使用者模型，讓他們站在自己所見和認知的狀況下自行完成測試，畢竟軟體服務也沒在每個功能都附說明書的，當他們踩完後客服可以依據踩過的經驗去寫顧客服務文件，針對客戶有可能有疑慮的地方先做準備
而行銷早在開發階段就要為產品上線時的宣傳做準備，而此時的驗收，就是確認他宣傳的方向和主軸有無偏離，並將宣傳資訊定案（包含畫面）
所以如果是以我回饋的經驗範例來說，專案真的不是pm一個人的，而是人人有責
標準社畜
是，你說的我了解，但那個大前提是
「團隊中各員都了解自己的職責並且保持良好的溝通，且相處融洽」
但以這個案例來說，如果組員(設計)，是不想溝通、不好配合的人，那麼PM本身就要拿出身為PM的本事，讓對方只能乖乖聽話。
例如案例中的狀況，看起來就蠻像是溝通階段時沒有規劃好，後面也提到「介面沒有按照設計的樣式呈現」，那就表示要不設計沒有安照規格書做、要不就是規格書有問題。
解決方法就真的是只能把規格書寫到近乎完美，並且要求設計落實執行。
那誰能要求設計呢？當然是PM囉，總不會每次都要上級主管出面吧？
舉個例子，你家準備裝潢，找了裝潢公司並且有專屬的設計師配合，設計師底下也有專業的水電、木工、泥作等等。
但是裝潢到尾聲準備進行驗收作業時，你發現木工並沒有按圖施作，那這時候你會找誰處理呢？
你舉的例子很好耶，就是要找要那個負責整體的人處理
iThome鐵人賽
看影片追技術